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1  Introduction 

What  ingredients  are  needed  to  enable  widespread  personal  teleconferencing  over  the  Internet  and  NREN? 
Certainly  the  integration  of  audio  and  video  compression  hardware  into  workstations  is  essential.  However, 
network  protocols  are  as  critical  to  this  goal.  This  is  the  major  focus  of  our  work  in  the  Multimedia 
Conferencing  Project  at  ISI.  Toward  this  end,  ISI  and  BBN  have  developed  an  experimental  packet 
teleconferencing  system  that  currently  is  operating  at  several  sites  on  the  Terrestrial  Wideband  Network, 
TWBnet  [1],  and  has  more  recently  been  ported  to  the  DARPA  Research  Testbed,  DARTnet,  for  further 
experimentation.  The  system  allows  geographically  separated  individuals  to  collaborate  by  combining 
real-time  packet  audio  and  video  with  shared  computer  workspaces,  sometimes  called  groupware. 

We  are  designing  and  implementing  protocols  at  a  number  of  levels  in  the  protocol  stack:  at  the  lower 
levels,  real-tiine  data  communication  services  for  the  Internet  in  general  [2-4];  and  at  hi|^  levels,  a 
connection  management  architecture  to  fKiliute  connections  among  heterogeneous  systems.  In  this  abstract, 
we  confuw  our  discussion  to  higher  level  issues:  an  overall  cormection  architecture,  a  connection  control 
protocol,  and  configuration  management 

2  A  Connection  Management  Architecture 

We  have  designed  a  framework  for  applications  such  as  teleconferencing  that  require  the  establishment  of 
multiple  partkipani,  multiple  media  sessions.  We  propose  that  such  applications  be  constructed  as  diown  in 
the  diagram  below.  The  central  component  that  orchestrates  the  multiparty,  multimedia  connections  is  the 
connection  manager.  Conceptually,  it  is  separate  from  user  interfaces  (UIs)  to  the  system,  which  sit  above  it 
offering  services  tq>  to  the  user  and  relaying  requests  down  from  the  user.  By  separating  the  connectioo 
manager  from  the  user  interface,  conference-oriented  tools  avoid  duplication  ^  effort;  this  encompasses 
management  of  preticipation,  authentication,  and  presentation  of  coordinated  UIs.  This  is  along  the  lines  of 
Swinehart’s  switching  kernel  [S]  and  is  related  to  Lantz’  and  Lauwers*  models  for  UIs  that  endow  programs 
with  the  ability  to  be  multi-user  [6].  The  connection  manager  is  also  separate  from  underlying  components, 
called  media  agenu,  which  handle  communication  protocol  decisions  (transport  and  internetwork  protocols) 
and  the  devices  specific  to  eadi  type  of  shared  media  (audio,  video,  groupware).  This  organization  also 
allows  the  connection  manager  to  convey  timing  information  between  media  agents  for  inter-media 
synchronization. 

We  refer  to  this  layered  organization  as  the  connection  management  architecture,  since  maiuigement  of 
connections  is  the  prinisry  focus  of  the  model  and  since  the  connection  manager  acts  as  the  conduit  through 
which  control  information  flows  between  layers.  Its  modularity  allows  functionally-equivalent  components  lo 
substitute  for  each  other.  Our  current  teleconferencing  system  is  the  forerunner  to  this  architecture,  but  we 
have  also  drawn  ideas  from  other  connection  management  schemes  [7-10].  While  these  schemes  are  diverse. 


each  has  suggested  the  need  for  a  connection  management  abstraction.  The  emphasis  of  our  architecture  is  to 
provide  reliability  across  WANs,  to  accommodate  heterogeneity,  and  to  facilitate  interoperability  with  other 
teleconferencing  impleineiuaiions. 


Connection 

Control 

Protocol 
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3  The  Connection  Control  Protocol 

The  Connection  Control  Protocol  (CCP)  is  an  qtplication  layer  protocol  used  by  connection  managers  to 
communicate  among  themselves.  It  is  ba^  on  the  protocol  used  by  the  Multimedia  Conference  Control 
Program  (MMCQ,  which  has  served  as  both  user  interface  and  connection  manager  for  the  existing  system 
[11].  The  OCP  is  essentially  a  multicast,  transaction-based  protocol.  It  aims  to  provide  reliable,  group 
communication  and  to  accommodate  variability  in  request-reply  response  time  due  to  WAN  operation  and  lo 
heterogeneous  end  system  configurations.  The  spedflcation  for  CCP  has  been  drafted  [12]  and 
implementation  is  underway. 

Conference  orchestration  is  achieved  through  use  of  a  distributed,  peer-to-peer  model.  Peer  connection 
managers  reside  on  machines  scattered  throughout  the  Internet  Each  connection  manager  acts  as  both  client 
and  server,  notifying  users  of  requests  from  other  connection  managers,  and  placing  requests  to  other 
connecdon  managers  on  die  local  user’s  behalf.  During  conference  setup,  a  coruiection  manager  first 
communicates  remolBly  with  peer  connection  managers  via  CCP,  then  communicates  locally  with  the  media 
agents  via  weO-defined  call  mterfMes  to  actually  create  the  underlying  voice,  video  and  groupware  data 
flows. 

The  CCP  qieciEcation  emphasizes  the  connection  establishment  and  disconnection  procedures.  A  main 
tadt  is  the  four-phase  conference  seoip  process.  During  conference  setup,  the  initiator  is  reqxNisible  for 
negotiating  a  common  set  of  capabilities,  requesting  participotion.  initiating  media  connections  and 
propagating  information  among  peers;  it  acts  as  a  leader  until  conference  creation  completes.  With  the 
conference  in  place,  the  initiator  reverts  to  having  no  qiecial  status,  and  other  sites  may  be  mviied,  join  or 
leave  the  conference  at  any  time.  When  a  participant  disconnects,  the  rest  of  the  conference  is  left  intact, 
unless  it  was  a  two-party  connection  which  would  te  tom  down  entirely. 
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Because  functionality  may  vary  greatly  between  teleconferencing  implementations,  the  protocol  must  be 
extensible.  Thus,  the  CCP  has  a  built-in  mechanism  that  acts  as  a  transparent  conduit  for  other  types  of 
operations  between  user  interfaces  and  media  agents.  These  operations  might  occur  during  or  outside  of  a 
conference,  without  CCP  having  to  know  the  particulars  of  each  operation.  An  example  would  be  a 
media-specific  fiinciioa  (e.g.,  mute  a  particular  audio  stream). 

Due  to  the  distributed  nature  of  the  system,  cooperating  connection  managers  may  get  out  of 
synchronization.  Site  A  thinks  it  is  conferencing  with  site  B,  but  site  B  thinks  it  is  not  in  conference  at  all. 
CXTP  counteracts  these  problems  by  exchanging  state  information  with  every  message,  triggering  active  state 
queries,  and  using  a  resynchronization  algorithm  to  resolve  state  mismatches. 


4  Configuration  Management 

Gaging  from  our  own  experience  with  WAN  conferencing,  as  the  number  of  sites  scales  up,  so  does  the 
likelihood  for  heterogeneity  among  them.  When  telecollaboraiion  becomes  popular  over  the  Internet,  users 
and  their  equipment  will  inevitably  fall  into  different  administrative  domains.  Decisions  on  codec  types, 
bounds  on  network  bandwidth,  the  number  of  cameras  connected,  etc.,  will  be  made  by  different  individuals. 
One  end  system’s  capabilities  or  configuration  is  likely  to  vary  from  another.  Therefore  one  of  the 
connection  manager's  functions  is  configuration  management  —  the  need  to  communicate  configuration 
information  and  to  implement  service  selection  (on  demand)  so  that  end  systems  siq)porting  Afferent 
combinations  of  services  can  still  be  interoperable  in  the  subset  of  compatible  services.  Although  we  are  in 
the  beginning  stages  of  the  configuration  management  design,  we  propose  several  mechanisms  to  deal  with 
heterogeneity:  a  configuration  language,  a  distributed  resource  locator  service,  and  a  resource  synthesizer. 

A  cor^iguration  language  must  be  developed  to  describe  resources  and  devices  located  at  each  end 
system.  This  language  will  categtvize  the  set  of  services  offered  by  each  system,  and  must  be  extensible  to 
accommodate  new  services  and  devices  as  they  are  added.  The  system  will  maintain  a  mapping  of 
configuration  attributes  to  media  agents,  allowing  die  connection  manager  module  to  choose  an  appropriate 
agent  or  agents  to  meet  configuration  requirements  made  by  applications.  This  is  crucial  for  the  negotiation 
phase  of  the  CG*  connection  establishment  procedure. 

We  also  expect  to  support  the  dynamic  configuration  of  shared  resources  so  that  multimedia  devices 
could  be  shared  among  users  or  applications.  For  example,  a  crossbar  switch  or  video  codec  might  be  shared 
among  users  on  a  LAN,  or  devices  such  as  video  bridges  or  coding  translators  might  be  remote  services 
available  to  users  throughout  the  Internet  The  system  will  also  provide  a  procedure  for  devices,  resources 
and  agents  to  register  themselves  as  available  to  be  shared  and  will  define  a  distributed  locator  service  lo 
provide  resource  directory  functions  —  the  resource  description,  its  location  in  the  network,  and  the 
associated  configuration  parameters. 
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In  those  instances  where  capabilities  at  end  systems  mismatch  entirely  (ix.,  no  compromise  configuration 
can  be  found),  a  resource  synthesizer  will  synthesize  solutions  to  configuration  requests  [13].  The  resource 


synihesizer  must  find  a  sequence  of  communication  mechanisms  and  intermediate  translators  to  construct 
paths  anoong  all  the  end  systems  in  the  connection.  The  resource  synthcj^izer  would  draw  information  firom 
the  locator  aervioe  about  shared  capabilities  that  could  be  used  throughout  the  networic.  We  expect  that 
experience  from  the  network  routing  domain  will  be  applicable  to  this  problem. 

5  Future  Work 

A  strategy  to  laing  widespread  teleconferencing  to  the  Internet  community  must  include  an  open 
connection  management  architecture.  That  architecture  must  address  issues  in  heterogeneous  configurations 
and  reliability  across  wide  area  networks.  The  blueprints  for  just  such  a  framework  have  been  outlined  in 
this  abstract  and  we  are  now  turning  our  efforts  toward  its  implementation. 
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